Adding a simulator + regopolicyinterpreter. #1558

matajoh · 2022-11-02T13:59:08Z

This PR separates all the interaction with Rego into its own extractable package called regopolicyinterpreter. Instead of calling Rego directly, the securitypolicy package now uses this package to implement Rego policies. Separating out the Rego interpreter behavior in this way allows the same code to be used by a new policyenginesimulator tool, which provides the ability to simulate security policy execution on the command line.

regopolicyinterpreter exposes various Rego things like modules and metadata in a typed way to make them easier to work with:

RegoPolicyInterpreter is the main interface
RegoModule is a standalone Rego module that can be included in the policy execution. There are AddModule and RemoveModule methods for modifying the interpreter to include various modules.
RegoQueryResult wraps the results that come from the Rego policy with some useful methods for extracting scalar data types (i.e. bool/int/float/string)
EnableLogging provides a way to get multiple levels of policy logging for debugging purposes, ranging from Info, which will output prints that come from the Rego policy itself, to Metadata, which will dump the entire policy metadata structure to the log with each interaction. This is primarily intended for offline use (e.g. by the simulator).

The policyenginesimulator tool uses RegoPolicyInterpreter to simulate policy enforcement. Usage:

  -commands string
        commands JSON
  -data string
        initial data state
  -log string
        log path
  -logLevel string
        None|Info|Results|Metadata (default "Info")
  -policy string
        policy Rego

The commands JSON allows the user to specify the type and order of the commands send by the host to the guest that will interact with the simulated policy, for example:

[
    {
        "name": "load_fragment",
        "input": {
            "issuer": "did:web:contoso.github.io",
            "feed": "contoso.azurecr.io/custom",
            "namespace": "custom",
            "local_path": "custom.rego"
        }
    },
    {
        "name": "mount_device",
        "input": {
            "target": "/mnt/layer0",
            "deviceHash": "16b514057a06ad665f92c02863aca074fd5976c755d26bff16365299169e8415"
        }
    },
    {
        "name": "mount_overlay",
        "input": {
            "target": "/mnt/overlay0",
            "containerID": "container0",
            "layerPaths": [
                "/mnt/layer0"
            ]
        }
    },
    {
        "name": "create_container",
        "input": {
            "containerID": "container0",
            "argList": [
                "/pause"
            ],
            "envList": [
                "PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin",
                "TERM=xterm"
            ],
            "mounts": [],
            "workingDir": "/",
            "sandboxDir": "/sandbox",
            "hugePagesDir": "/hugepages"
        }
    }
]

internal/tools/policyenginesimulator/README.md

internal/tools/policyenginesimulator/samples/simple_custom/custom.rego

internal/tools/policyenginesimulator/README.md

pkg/regopolicyinterpreter/regopolicyinterpreter.go

internal/tools/policyenginesimulator/README.md

pkg/regopolicyinterpreter/regopolicyinterpreter.go

anmaxvl · 2022-12-13T09:49:57Z

pkg/securitypolicy/securitypolicy.go

@@ -14,6 +15,12 @@ import (
 	"github.com/pkg/errors"
 )

+//go:embed framework.rego
+var FrameworkCode string


why is this here? shouldn't this be part of rego enforcer?

Since the policy simulator can run in either windows or Linux, and since it needs this string to simulate policies, it made sense to move it to securitypolicy.go, which is not boxed by a build tag.

This PR separates all the interaction with Rego into its own extractable package called `regopolicyinterpreter`. Instead of calling Rego directly, the `securitypolicy` package now uses this package to implement Rego policies. Separating out the Rego interpreter behavior in this way allows the same code to be used by a new `policyenginesimulator` tool, which provides the ability to simulate security policy execution on the command line. `regopolicyinterpreter` exposes various Rego things like modules and metadata in a typed way to make them easier to work with: - `RegoPolicyInterpreter` is the main interface - `RegoModule` is a standalone Rego module that can be included in the policy execution. There are `AddModule` and `RemoveModule` methods for modifying the interpreter to include various modules. - `RegoQueryResult` wraps the results that come from the Rego policy with some useful methods for extracting scalar data types (i.e. `bool`/`int`/`float`/`string`) - `EnableLogging` provides a way to get multiple levels of policy logging for debugging purposes, ranging from `Info`, which will output prints that come from the Rego policy itself, to `Metadata`, which will dump the entire policy metadata structure to the log with each interaction. This is primarily intended for offline use (e.g. by the simulator). The `policyenginesimulator` tool uses `RegoPolicyInterpreter` to simulate policy enforcement. Usage: ``` -commands string commands JSON -data string initial data state -log string log path -logLevel string None|Info|Results|Metadata (default "Info") -policy string policy Rego ``` The commands JSON allows the user to specify the type and order of the commands send by the host to the guest that will interact with the simulated policy, for example: ``` json [ { "name": "load_fragment", "input": { "issuer": "did:web:contoso.github.io", "feed": "contoso.azurecr.io/custom", "namespace": "custom", "local_path": "custom.rego" } }, { "name": "mount_device", "input": { "target": "/mnt/layer0", "deviceHash": "16b514057a06ad665f92c02863aca074fd5976c755d26bff16365299169e8415" } }, { "name": "mount_overlay", "input": { "target": "/mnt/overlay0", "containerID": "container0", "layerPaths": [ "/mnt/layer0" ] } }, { "name": "create_container", "input": { "containerID": "container0", "argList": [ "/pause" ], "envList": [ "PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin", "TERM=xterm" ], "mounts": [], "workingDir": "/", "sandboxDir": "/sandbox", "hugePagesDir": "/hugepages" } } ] ``` Signed-off-by: Matthew A Johnson <[email protected]>

Signed-off-by: Matthew A Johnson <[email protected]>

internal/tools/policyenginesimulator/main.go

internal/tools/policyenginesimulator/README.md

Signed-off-by: Matthew A Johnson <[email protected]>

pkg/regopolicyinterpreter/regopolicyinterpreter.go

Related work items: microsoft#1416, microsoft#1558, microsoft#1572, microsoft#1597, microsoft#1600, microsoft#1607, microsoft#1611, microsoft#1616

* Adding a simulator + regopolicyinterpreter. This PR separates all the interaction with Rego into its own extractable package called `regopolicyinterpreter`. Instead of calling Rego directly, the `securitypolicy` package now uses this package to implement Rego policies. Separating out the Rego interpreter behavior in this way allows the same code to be used by a new `policyenginesimulator` tool, which provides the ability to simulate security policy execution on the command line. `regopolicyinterpreter` exposes various Rego things like modules and metadata in a typed way to make them easier to work with: - `RegoPolicyInterpreter` is the main interface - `RegoModule` is a standalone Rego module that can be included in the policy execution. There are `AddModule` and `RemoveModule` methods for modifying the interpreter to include various modules. - `RegoQueryResult` wraps the results that come from the Rego policy with some useful methods for extracting scalar data types (i.e. `bool`/`int`/`float`/`string`) - `EnableLogging` provides a way to get multiple levels of policy logging for debugging purposes, ranging from `Info`, which will output prints that come from the Rego policy itself, to `Metadata`, which will dump the entire policy metadata structure to the log with each interaction. This is primarily intended for offline use (e.g. by the simulator). The `policyenginesimulator` tool uses `RegoPolicyInterpreter` to simulate policy enforcement. Usage: ``` -commands string commands JSON -data string initial data state -log string log path -logLevel string None|Info|Results|Metadata (default "Info") -policy string policy Rego ``` The commands JSON allows the user to specify the type and order of the commands send by the host to the guest that will interact with the simulated policy, for example: ``` json [ { "name": "load_fragment", "input": { "issuer": "did:web:contoso.github.io", "feed": "contoso.azurecr.io/custom", "namespace": "custom", "local_path": "custom.rego" } }, { "name": "mount_device", "input": { "target": "/mnt/layer0", "deviceHash": "16b514057a06ad665f92c02863aca074fd5976c755d26bff16365299169e8415" } }, { "name": "mount_overlay", "input": { "target": "/mnt/overlay0", "containerID": "container0", "layerPaths": [ "/mnt/layer0" ] } }, { "name": "create_container", "input": { "containerID": "container0", "argList": [ "/pause" ], "envList": [ "PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin", "TERM=xterm" ], "mounts": [], "workingDir": "/", "sandboxDir": "/sandbox", "hugePagesDir": "/hugepages" } } ] ``` Signed-off-by: Matthew A Johnson <[email protected]>

matajoh requested a review from a team as a code owner November 2, 2022 13:59